\documentclass[12pt,a4paper,spanish]{article} 

\usepackage{graphicx} %option specific for pdfLatex compilation
\usepackage{makeidx}
\usepackage{lscape}
\usepackage[section]{placeins}

\usepackage[spanish]{babel}
\usepackage[utf8]{inputenc} 
\usepackage{indentfirst}
\usepackage[hang,bf]{caption}

\title{Taller de Programación II: Trabajo Práctico}
\author{Garay, Ignacio y Bosch, Florencia}

\usepackage{geometry}

\newcommand{\imgdir}{./img}
\graphicspath{{\imgdir/}}

\begin{document}
\input{./title.tex}
\newpage
\tableofcontents
\newpage
\section{Análisis}
Para este trabajo práctico se requirió integrar un nuevo módulo a la herramienta de desarollo 
guiado por modelos (MDD -- \textit{model driven development}), cuyo desarrollo comenzó en 
cuatrimestres anterioresa por compañeros nuestros. 

Nos han entregado el código de un trabajo anterior, con dos modulos implementados:
\begin{enumerate}
	\item \textbf{Modulo de modelado de entidades y relaciones (ERM):} este módulo permite 
		el modelado de datos, usando una extensión del modelo de entidades y relaciones.
		Además, por ser el primero en ser desarrollado, permitía la creación y 
		administración de proyectos.
	\item \textbf{Modulo de modelado de comportamiento (FSM):} este módulo integra el 
		modelado de comportamientos basado en máquinas de estado finito; y permite 
		desarrollar diagramas de estado de un sistema, en los que cada estado representa
		una interfaz gráfica con el usuario, y cada transición una función que el usuario
		puede activar en la interfaz.	
\end{enumerate}

El módulo que implementamos nosotros es el \textbf{módulo de transformación de modelos de datos a
diagramas de clases del dominio (DM)}, en el que a partir de un diagrama de entidades y relaciones
derivamos un diagrama de clases de dominio en notación UML 2.0. A su vez, también realiza conversiones
de FSM a entidades de dominio, creando clases por cada interfaz, con sus componentes.

\subsection{UML}
UML es un lenguaje estandarizado de modelado creado por trabajadores de Rational Software en la
década de 1990 y usado extensivamente para el desarrollo de software. UML provee muchos
tipos de diagramas para modelar elementos de negocio, de datos y de implementación.

Los diagramas de clases de UML son usados para mostrar la estructura de la implementación, y a
pesar de que la versión 2.0 provee muchos componentes, el alcance de nuestro trabajo sólo 
requiere de tres:

\begin{itemize}
	\item Clases: son equivalentes a las entidades en el modelo entidad-relación; y son 
		representadas por rectángulos divididos horizontalmente en tres partes: la primera
		contiene el nombre de la clase, la segunda sus atributos y la tercera sus
		métodos u operaciones.
	\item Vínculos: demuestran relaciones entre clases. UML provee varios tipos de relaciones:
		asociación, agregación, composición, generalización y dependencia. Los vínculos en
		los diagramas de clases son equivalentes a las interrelaciones en el MER.
	\item Multiplicidades: especifican las restricciones numéricas de la relación entre clases
		y son similares a las cardinalidades en el MER.

\end{itemize}

En la figura 1 se muestra un ejemplo de diagrama de clases de dominio tomado de la bibliografía.

\begin{figure}[h]
	\centering
	\includegraphics[scale=0.55]{EjDM}
	\caption{Un ejemplo de diagrama de clases de dominio.}
\end{figure}

\section{Especificación}

\subsection{Casos de uso}

En el trabajo práctico se han implementado dos casos de uso.

\subsubsection{Editar diagrama de clases de modelo de dominio}
    \begin{tabular}{|p{4cm}|p{11cm}|}
            \hline
            \textbf{Caso de uso:} & Editar diagrama de clases de modelo de dominio. \\
            \hline
            \textbf{Descripción:} & Permite que el usuario pueda agregar, modificar y reposicionar
		clases y relaciones de un diagrama. Además, el usuario puede persistir su trabajo
		para continuarlo en otro momento y exportarlo en formato de imagen \texttt{jpeg} o imprimirlo. \\
            \hline
            \textbf{Actor primario:} & Usuario. \\
            \hline
            \textbf{Precondiciones:} & Ninguna. \\
            \hline
            \hline
	    \textbf{Flujo principal:} & \
		\begin{enumerate}
			\item El usuario abre un diagrama guardado anteriormente o bien crea uno 
				nuevo con nombre válido.
				
			\item El usuario agrega una clase:
			\begin{enumerate}
				\item Presiona el botón ``Entity'' para crear una entidad.
				\item Seleccionar entre ``Class'' y ``Interface''.  
				\item Establece un nombre válido para la misma desde la pestaña ``general''.
				\item Agrega métodos desde la pestaña ``operations''. Si lo deseara, puede presionar el boton ``add'' para agregar parámetros. 
				\item Agrega atributos desde la pestaña ``attributes''.
				\item Selecciona el botón ``Finish'' para finalizar con la creación.
				\item \textit{Clickea} algún lugar del lienzo para insertar la nueva clase.
			\end{enumerate}
			
			\item El usuario agrega una relación:
			\begin{enumerate}
				\item Presiona el botón ``Relationship'' para vincular clases.
				\item Selecciona el tipo de relación que desea establecer entre las clases.
				\item Selecciona las clases de origen y destino.
				\item Selecciona cardinalidades para los vínculos de origen y destino.
				\item Selecciona el botón ``Finish'' para finalizar con la creación.
			\end{enumerate}

			\item El usuario guarda el diagrama seleccionando el botón ``Save''.
			\item El usuario exporta el diagrama seleccionando el botón ``Export''.
			\item El usuario imprime el diagrama seleccionando el botón ``Print''.			

		\end{enumerate}	\\
	    \hline
    \end{tabular}

\subsubsection{Transformar ERM o FSM a clases de modelo de dominio}
    \begin{tabular}{|p{4cm}|p{10cm}|}
            \hline
            \textbf{Caso de uso:} & Transformar diagrama ERM o FSM a clases de modelo de dominio. \\
            \hline
            \textbf{Descripción:} & Permite que el usuario convierta automáticamente un diagrama ERM o FSM en un diagrama de clases de modelo de dominio. \\
            \hline
            \textbf{Actor primario:} & Usuario. \\
            \hline
            \textbf{Precondiciones:} & Ninguna. \\
            \hline
            \hline
	    \textbf{Flujo principal:} & 
		\begin{enumerate}
			\item El usuario selecciona el botón de ``Convert''.
			
			\item El usuario selecciona el proyecto a convertir, ya sea ERM o FSM.
			
			\item El sistema despliega el proyecto convertido. El mismo mantiene las posiciones de las entidades de los otros proyectos.
			\item El usuario puede mover y editar las nuevas relaciones y trabajar con el mismo como si fuera un proyecto DM.
		\end{enumerate}	\\
            \hline
	    \hline
	    \textbf{Postcondiciones:} & Se está editando un diagrama de clases de modelo de dominio 
		equivalente al de entidad-relación original. \\
	    \hline
    \end{tabular}

\subsection{Transformación ERM}
Para realizar la transformación, se utiliza el siguiente algoritmo, propuesto por la bibliografía
elegida:

\begin{enumerate}
	\item Para cada entidad en el diagrama de entidad-relación
		\begin{enumerate}
			\item crear una clase UML con el mismo nombre.
			\item agregar los atributos de la entidad a la clase resultante.
		\end{enumerate}
	\item Para cada relación:
		\begin{enumerate}
			\item Generar una clase de relación que contenga los atributos de la misma.
			\item Generar una asociación entre todas las clases participantes y la clase de relación.		
			\item Si hay nombre de roles especificados, agregarlos a la generalización o asociación.	
			\item Si hay cardinalidades especificadas, agregar las especificaciones a los tipos resultantes como multiplicidades.		
		\end{enumerate}
\end{enumerate}


\subsection{Transformación FSM}
La transformación consiste en los siguientes pasos:

\begin{enumerate}
	\item Para cada interfaz:
		\begin{enumerate}
			\item crear una clase UML con el mismo nombre.
			\item Los componentes de dicha interfaz se agregarán como atributos a la clase.
		\end{enumerate}
	\item Para cada transición:
		\begin{enumerate}
			\item Generar una relación de asociacion entre las entidades involucradas.
		\end{enumerate}
\end{enumerate}


\section{Diseño}
Se diseñó el trabajo utilizando una arquitectura MVC, dado que se estuvo frente a un caso de 
aplicación típica: un programa con interfaz de usuario que usa varios módulos diferentes,
idealmente poco acoplados para facilitar la reutilización de código.

Se dividió la aplicación en paquetes según se muestra en la figura 2. Un paquete, common, contiene
clases utilitarias utilizadas por los tres módulos hijo o bien cuando no hay proyectos cargados.
Cada uno del resto de los paquetes es utilizado según el modo de edición.

\begin{figure}[h]
	\centering
	\includegraphics[scale=0.55]{DiagramaPaquetes}
	\caption{diagrama de paquetes de la solución.}
\end{figure}

Se muestra en la figura 3 el modelo de la funcionalidad incorporada de edición de diagramas de modelo de 
dominio. La misma representa las entidades de dominio que se utilizaron para crear los diagramas.

\newpage
\begin{figure}[!ht]
	\centering
	\includegraphics[angle=90,scale=0.50]{diagramaModelo}
	\caption{diagrama de clases del modelo del editor de diagramas de modelo de dominio.}
\end{figure}


\section{Problemas encontrados}
\begin{itemize}
\item Baja cobertura de tests. Encontramos el proyecto con menos de un 0.15 de índice de cobertura. Dicha métrica se aumentó a casi un 0.7 utilizando un complemento de google para testing automatizado.
\item Código legacy, con pocos tests relevantes, escasa o nula documentación. Existía un fuerte acoplamiento de
código, lo cual demandó muchas horas tanto en comprensión del mismo como en refactorización e integración.
\item Encontramos que había herramientas mal utilizadas. Una por ejemplo, Jgraph, en la cual se estaban haciendo las modificaciones de las entidades gráficas de forma errónea.
\end{itemize}

\section{Conclusión}
\begin{itemize}
\item Los esfuerzos pequeños que se toman para desarrollar de manera más prolija, si bien no se notan al corto plazo, presentan grandes beneficios al mediano y largo plazo, dado que pueden minimizar el tiempo incurrido en tareas de investigación y refactorización de código. 
\item La separación en capas presenta grandes beneficios al momento de implementar un sistema, dado que permitió la simple integración de un nuevo modelo de dominio y persistencia. Aunque agregar entidades en capaz compartidas, como ser Vista y Controladores llevó mucho trabajo por lo anteriormente mencionado.


\section{Bibliografía}
\begin{itemize}
	\item Ou, Yongzhen (2008). \textit{On mapping between UML and Entity-Relationship model.} 
		Fakultät für Mathematik und Informatik, Universität Konstanz; Constanza, Alemania. 
	\item Elmasri, Ramez; Navathe, Shamkant B. (2010). \textit{Fundamentos de sistemas de base
		de datos.} Sexta edición. Ed. Pearson Addison--Wesley. ISBN: 987-84-7829-085-7.
	\item Object Management Group (2014). \textit{Unified Modeling Language -- resource page.}
		Disponible en http://www.uml.org/
	\item Fowler, Martin (18/6/2006). \textit{GUI Architectures.} \\
		Disponible en: http://martinfowler.com/eaaDev/uiArchs.html
\end{itemize}


\end{document}
